<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="zh" xml:lang="zh" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<head>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Task Descriptor: Identify Services</title>
<meta name="uma.type" content="TaskDescriptor">
<meta name="uma.name" content="identify_services">
<meta name="uma.presentationName" content="Identify Services">
<meta name="uma.guid" content="_WnOpAEocEdqrjq4i3fchvA">
<meta name="element_type" content="TaskDescriptor">
<meta name="filetype" content="description">
<meta name="role" content="">
<link rel="StyleSheet" href="./../../css/default.css" type="text/css">
<script src="./../../scripts/ContentPageResource.js" type="text/javascript" language="JavaScript"></script><script src="./../../scripts/ContentPageSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../scripts/ContentPageSubSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../scripts/ActivityTreeTable.js" type="text/javascript" language="JavaScript"></script><script src="./../../scripts/ProcessElementPage.js" type="text/javascript" language="JavaScript"></script><script src="./../../scripts/ContentPageToolbar.js" type="text/javascript" language="JavaScript"></script><script src="./../../scripts/contentPage.js" type="text/javascript" language="JavaScript"></script><script src="./../../scripts/processElementData.js" type="text/javascript" language="JavaScript"></script><script type="text/javascript" language="JavaScript">
					var defaultQueryStr = '?proc={002674F9-6511-4D15-8623-B761D8C48986}&path={002674F9-6511-4D15-8623-B761D8C48986},{F2160C54-F666-4736-9982-FC7F58F15FAD},_WnOpAEocEdqrjq4i3fchvA';
					var backPath = './../../';
					var imgPath = './../../images/';
					var nodeInfo=null;
					contentPage.preload(imgPath, backPath, nodeInfo, defaultQueryStr, true, true, false);
				</script>
</head>
<body>
<div id="breadcrumbs"></div>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td valign="top">
<div id="page-guid" value="_WnOpAEocEdqrjq4i3fchvA"></div>
<table border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td class="pageTitle" nowrap="true">Task Descriptor: Identify Services</td><td width="100%">
<div align="right" id="contentPageToolbar"></div>
</td><td width="100%" class="expandCollapseLink" align="right"><a name="mainIndex" href="./../../index.htm"></a><script language="JavaScript" type="text/javascript" src="./../../scripts/treebrowser.js"></script></td>
</tr>
</table>
<table width="100%" border="0" cellpadding="0" cellspacing="0">
<tr>
<td class="pageTitleSeparator"><img src="./../../images/shim.gif" alt="" title="" height="1"></td>
</tr>
</table>
<div class="overview">
<table width="97%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="50"><img src="./../../images/taskdes_lg_dgm32.gif" alt="" title=""></td><td>
<table class="overviewTable" border="0" cellspacing="0" cellpadding="0">
<tr>
<td valign="top">This task identifies the design elements of a service-oriented solution in terms of services and partitions and documents the initial specification of those services.</td>
</tr>
<tr>
<td>Based on Method Task: <a href="./../../rup_soa_plugin/tasks/identify_services_565F8B8A.html" guid="{0BF79161-A484-4C48-B72D-DA381DA05886}">Identify Services</a></td>
</tr>
</table>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Relationships</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<th class="sectionTableHeading" scope="row">Roles</th><td class="sectionTableCell" width="30%"><span class="sectionTableCellHeading">Main:
								</span>
<ul>
<li>
<a href="./../../rup/capabilitypatterns/rup_software_architect_8B6C5D41.html" guid="_COWYtRi2Edq_uI8xTPML6g">软件设计人员</a>
</li>
</ul>
</td><td class="sectionTableCell" width="30%"><span class="sectionTableCellHeading">Additional:
								</span></td><td class="sectionTableCell"><span class="sectionTableCellHeading">Assisting:
								</span></td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row">Inputs</th><td class="sectionTableCell" width="30%"><span class="sectionTableCellHeading">Mandatory:
								</span>
<ul>
<li>
<a href="./../../rup/capabilitypatterns/soa_service_model_67217F6C.html" guid="_ZQarcjbZEdqdbfmtFQj8qA">Service Model</a>
</li>
</ul>
</td><td class="sectionTableCell" width="30%"><span class="sectionTableCellHeading">Optional:
								</span>
<ul>
<li>None</li>
</ul>
</td><td class="sectionTableCell"><span class="sectionTableCellHeading">External:
								</span>
<ul>
<li>None</li>
</ul>
</td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row">Outputs</th><td class="sectionTableCell" colspan="3">
<ul>
<li>
<a href="./../../rup/capabilitypatterns/soa_service_model_67217F6C.html" guid="_ZQarcjbZEdqdbfmtFQj8qA">Service Model</a>
</li>
</ul>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Steps</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="sectionTableCell">
<div class="stepHeading"> Introduction </div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><a id="Introduction" name="Introduction"></a> 
<p>
    This section outlines guidance on how the <i>Software Architect</i> or <i>Designer</i> can identify services. This
    process of service identification and clustering into <a class="elementLinkWithUserText" href="./../../rup_soa_plugin/workproducts/soa_svce_model_svce_spec_37E89A91.html" guid="{20F06B5E-95D5-422C-AB68-7C213D28533A}"><i>Service Specifications</i></a> and <i><a class="elementLinkWithUserText" href="./../../rup_soa_plugin/workproducts/soa_svce_model_svce_provider_C00D3410.html" guid="{8427751F-3C14-4CEB-9816-5112BDB91EED}">Service Providers</a></i> can be approached from a number of perspectives
    and the choices below may be used alone or most likely in combination in any particular project. The identification of
    services is most likely one of the first tasks in the modeling of a service-oriented solution. Therefore, errors made
    during identification can flow through detailed design and implementation tasks.
</p>
<p>
    The following diagram demonstrates the differing approaches to service identification. These are not mutually
    exclusive, but the choices of which ones are appropriate will need to take into account wider process and project
    concerns. Each of the colored ovals represents one of the techniques described below. There are two forms of
    collaboration-based identification where the collaboration may be identified using business-process modeling or
    use-case modeling.
</p>
<p align="center">
    <img height="133" alt="Diagram is described in the textual content." src="./../../rup_soa_plugin/tasks/resources/soa_svce_identification-05.gif"     width="421" border="0" />
</p>
<p>
    However, one of the first decisions to make, and it is independent of the approaches above, is whether the
    identification is purely based on the understanding of Operations which are later aggregation into services or whether
    a set of services are already known and Operations are added to services as identified.
</p>
<p>
    <b>Service-first</b>; this technique is common to both object-oriented and component based development where the
    Classes of objects or components are identified first, presumably using an analysis technique to identify the classes
    of "things" in some business or technical domain. Then, as collaborations between objects are analyzed, the operations
    (responsibilities of the object) are identified and added to the classes. In the same way, Services may be identified
    from <i><a class="elementLinkWithUserText" href="./../../rup_soa_plugin/guidances/concepts/domain_design_77B2F855.html" guid="1.2602759670310655E-305">Domain Analysis</a></i> and augmented by the Operations identified in the approaches
    below.
</p>
<p>
    <b>Operation-first</b>; however, some critics have pointed out that services are not like classes and objects or
    components. Services may manage a set of resources, but the service/resource relationship is fundamentally different to
    the class/object relationship. As such, different analysis techniques are required and tend to favor the late
    identification of services by aggregating a set of identified Operations into some logical grouping.
</p>
<p>
    The examples below will demonstrate the use of a Service-first technique because it is more easily used by those
    familiar with similar guidance in Neusoft Unified Process (RUP).
</p></td>
</tr>
</table>
</div>
<div class="stepHeading"> Top-Down, Business Process Driven </div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><a id="Process_Analysis" name="Process_Analysis"></a> 
<p>
    In the discussion of business alignment of services in the <i><a class="elementLink" href="./../../rup_soa_plugin/guidances/guidelines/service_CA5D991C.html" guid="2.1757522381974088E-306">Service</a></i>
    guideline, the connection between business models and service identification was discussed. In general, this approach
    provides a very tight connection between business stakeholders/users and the IT organization implementing services by
    allowing for service operations to directly support the tasks identified in process models. In general,
    business-process models focus on tasks performed by roles and/or resources in an organization to accomplish some task,
    usually to provide value in the form of product or service to an external party such as a customer or partner. The
    process is an ordered set of such tasks, possibly decomposed into sub-processes. It has associated organization,
    resource, and data models to capture all aspects of the process including not only performing roles, but required/used
    resources, ownership of resources, accountability, definitions of items passed into and out of tasks, and so on.
</p>
<p>
    The following demonstrates a very simple process model using the IBM WebSphere Business Integration Modeler.
</p>
<p align="center">
    <img height="289" alt="Diagram is described in the textual content." src="./../../rup_soa_plugin/tasks/resources/soa_svce_identification-03.gif"     width="687" border="0" />
</p>
<p>
    In this case, each horizontal swimlane represents a particular role performing tasks in the process. The process starts
    with the green circle, ends with the red outlined circle, and does have data flowing between some tasks (in the form of
    a loan request). This process, while obviously trivial and contrived, does demonstrate the high level of tasks. They
    may be atomic actions from a business point of view, but obviously would require a number of steps when decomposed to
    the IT level. In general, in object-oriented development of component based development, we would then treat each
    individual task from the business view as a use case at the IT view and decompose into sets of components and classes
    to form the implementation of the use case.
</p>
<p>
    In a service-oriented solution, the service is identified at a similar level of granularity. It is commonly assumed
    that the operations on a service specification will correspond 1:1 with the atomic tasks identified in a business
    process model. While this is an attractive approach and may, if carefully done, achieve the right results, it also
    tends to lead to the assumption that such once services are identified, they may be directly implemented as they are
    described in the process model. Specifically each role (swimlane) will become a named service with each task within the
    swimlane created as an operation on the corresponding service.
</p>
<p>
    What this approach fails to take into consideration is that there are non-functional requirements that affect the kind
    of service to be developed, the way operations are identified on services, and so forth. The level of detail usually
    captured by such tools does not include enough for example to capture security, quality of service,or manageability
    policies, for example. By transforming the process into a set of <i>candidate</i> service specifications in a service
    model provides a starting point, but should be considered only as a starting point from which further analysis is
    performed before the design model is developed which describes the actual implementation.
</p></td>
</tr>
</table>
</div>
<div class="stepHeading"> Top-Down, Use Case Driven </div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><a id="Use_Case_Analysis" name="Use_Case_Analysis"></a> 
<p>
    In the development of more traditional component-based and object-oriented solutions, there tends to be a set of
    transformations across levels of abstraction and adding levels of detail from Use Cases down to system design. This is
    especially true when you take a Business Use Case as the starting point, as demonstrated in the guideline <i>Going from
    Business Models to Systems;</i> where the guidance demonstrates how to get from Business Use Cases to System Use Cases,
    we still have to develop an actual design model from there.
</p>
<p>
    The work product <i>Business Use Case</i> does describe the relationship between business processes and business use
    cases. So, certainly some of the comments made in the last section are also relevant here. Fortunately, we can also
    draw a parallel to the guideline provided for going to system-use cases in defining how a service model can be derived
    from a Business Use Case Model, as shown below.
</p>
<p align="center">
    <img height="385" alt="Diagram is described in the textual content." src="./../../rup_soa_plugin/tasks/resources/soa_svce_identification-02.gif"     width="481" border="0" />
</p>
<p>
    This more direct connection between the business-analysis model and the service model allows for not only services that
    can be seen to support the business needs, but by having less transformations between the expression of business needs
    and the solution, we can more effectively respond to change in the Business Use Case or Analysis Models. Another
    important aspect is that as the Business Use Case model also includes the Business Goals that are driving the business,
    it is now much easier to actually identify the alignment between Services and Goals. For example, it is now possible to
    list, for any Service Specification, all the Business Goals to which it contributes. For any Business Goal we can list
    the Services actually deployed in our IT organization that contribute to the goal , by following the connection from
    service to service specification.
</p>
<p>
    In modeling the example above, it is assumed that there is a traceable relationship between the service specifications
    derived from the business workers. Such a relationship allows us to ensure that if the definition of elements in the
    business analysis model change, the <em>designer</em> responsible for the service model can analyze the change and its
    impact on the service specifications and message definitions.
</p></td>
</tr>
</table>
</div>
<div class="stepHeading"> Data Driven </div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><a id="Data_Driven" name="Data_Driven"></a> 
<p>
    For most business-driven IT organizations, understanding and managing data in the form of complex <i><a class="elementLinkWithUserText" href="./../../rup_bm/workproducts/rup_business_entity_638A1D00.html" guid="{9A14ED32-2AC5-457E-93B8-474642D33A50}">Business Entities</a></i> is key to the analysis and design of solutions.
    As such, many solutions will include services that act as data-management services and the identification of services
    will tend to focus more on the <i><a class="elementLink" href="./../../rup/workproducts/rup_data_model_65B46980.html" guid="{9DCF1723-1A21-4F48-BEDE-DBC543489682}">数据模型</a></i>, <i><a class="elementLinkWithUserText" href="./../../rup_soa_plugin/guidances/concepts/domain_design_77B2F855.html" guid="1.2602759670310655E-305">Domain
    Model</a></i> or <i><a class="elementLink" href="./../../rup_bm/workproducts/rup_business_analysis_model_9449F63A.html" guid="{CF53445C-3351-46C6-810E-8251830029A7}">业务分析模型</a></i>. In terms of application reengineering to service-oriented
    solutions, data models have to be developed from the existing applications that can be used to identify coherent
    subsets that can be treated as autonomous services.
</p>
<p>
    This topic is dealt with in more detail in the guideline <i><a class="elementLink" href="./../../rup_soa_plugin/guidances/guidelines/service_data_encapsulation_F424F20E.html" guid="1.6727924656888407E-305">Service Data Encapsulation</a></i>.
</p></td>
</tr>
</table>
</div>
<div class="stepHeading"> Rule Driven </div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><a id="Rule_Driven" name="Rule_Driven"></a> 
<p>
    Certain classes of solutions tend to rely heavily on the use of <i>Business Rules</i> to extract the variability from
    the solution and externalize such that the rules can evolve outside of the main application logic. From a Business
    Analysis Model including Business Entities and Business Rules, it is possible to define services that encapsulate the
    business rules, externalizing them from the rest of the logic of the solution. The following diagram demonstrates a
    small, sample business-analysis model showing two business rules attached to the business entity named Order. These
    rules, as they are attached to a business entity, are most likely to correspond to invariants on the entity and so will
    be evaluated on any change in state of the entity. Rules may also be attached to actions or processes and are more
    often evaluated as pre-conditions or post-conditions for the action.
</p>
<p align="center">
    <img height="194" alt="Diagram is described in the textual content." src="./../../rup_soa_plugin/tasks/resources/soa_svce_identification-06.gif"     width="481" border="0" />
</p>
<p>
    In modeling the example above, it is assumed that there is a traceable relationship between the service specifications
    derived from the business rules and between the message(s) derived from the business entity.
</p>
<p>
    In many cases complex rules are aggregated into Rule Sets, these are much more of a match for the granularity of
    service, allowing, for example, a document to be passed to the validation service where the set of rules are evaluated
    and the results returned. From the example above, we can easily imagine that the validation services actually embody
    quite a complex set of rules for validating the compatibility of items ordered, quantities, and so on.
</p></td>
</tr>
</table>
</div>
<div class="stepHeading"> Bottom-Up, Exposing Existing Assets </div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><a id="Legacy_Renewal" name="Legacy_Renewal"></a> 
<p>
    One must not forget that very few solutions are built without consideration to existing applications that either will
    provide functionality to support the solution or with which the solution must interact. As such it is vital that
    existing legacy applications that will be reused as part of any solution be cataloged and their functionality
    identified. With a service-oriented solution, we are able to take a number of routes to integrate new services with
    existing functionality. These are demonstrated in the figure below:
</p>
<ul>
    <li>
        <b>Wrap existing function as a service</b>. In this case, we are looking to leave the function as-is, but use tools
        or middleware to expose the existing function as a service. For example, IBM provides the capability to expose
        legacy CICS transactions as SOAP Web services.
    </li>
    <li>
        <b>Wrap and replace existing function with a service</b>. In this case, we wrap a function as above, but we use the
        resulting service specification to redevelop the service at a later date, replacing the original service and having
        clients redirected to the new implementation.
    </li>
    <li>
        <b>Use an adapter more amenable to service invocation</b>. In some cases, it is not possible to wrap a function and
        expose it as a service, but may be possible to wrap the function in something more able to integrate, such as a
        message queuing interface or the Java Connector Architecture (JCA). This allows new services to access the function
        in-place.
    </li>
    <li>
        <b>Integrate the function into the service</b>. Obviously in some cases, it is possible for the new service to
        access the legacy function in-place, simply using the function as a logical component within the implementation of
        the service.
    </li>
</ul>
<p align="center">
    <img height="151" alt="Diagram is described in the textual content." src="./../../rup_soa_plugin/tasks/resources/soa_svce_identification-04.gif"     width="397" border="0" />
</p>
<p>
    It should be considered that the third and fourth options provide the most flexibility because they use the existing
    function but do not continue to expose the function as-is to clients. On the other hand, the first and second options
    may introduce issues with the wrapping of existing functions as services because the performance of Web-service
    protocols and mismatches between native data formats and XML may introduce performance concerns.
</p>
<h4>
    Wrapping Existing Assets as a Services Pattern
</h4>
<p>
    In some cases, however, it is expedient to develop a legacy service partition where a set of low-level legacy functions
    are exposed individually as services. This partition is only accessible to higher level services that utilize them in
    presenting a more granular business-aligned specification to consumers. This encapsulation of the legacy functions
    should be seen as a temporary solution and should only be undertaken if the performance characteristics of the wrapping
    technology is well understood. For more information see the concept <i><a class="elementLink" href="./../../rup_soa_plugin/guidances/concepts/solution_partitioning_352116F8.html" guid="1.6501323286225543E-305">Solution Partitioning</a></i>.
</p>
<p>
    One way to look at the wrapping of a legacy function is a very simplified form of the <i><a class="elementLink" href="./../../rup_soa_plugin/workproducts/soa_svce_model_svce_provider_C00D3410.html" guid="{8427751F-3C14-4CEB-9816-5112BDB91EED}">Service Provider</a></i> model element, with a single service realizing a
    single specification with only a single operation. The following diagram demonstrates this pattern for the legacy
    function "UpdateCustomerAddress".
</p>
<p align="center">
    &nbsp;<img height="162" alt="Diagram is described in the textual content."     src="./../../rup_soa_plugin/guidances/guidelines/resources/soa_svce_identification-01.gif" width="512" border="0" />
</p>
<p>
    In tailoring this pattern, you may wish to do the following:
</p>
<ul>
    <li>
        It is likely that a set of existing functions will be provided by the same component so the same service provider
        should be used.
    </li>
    <li>
        The pattern above was generated automatically; it might be preferable to rename the default operation name from
        "exec${service}".
    </li>
    <li>
        Similarly, it would be valuable to rename the default generated messages; also at this point, the message
        structures should be modeled.
    </li>
    <li>
        The default pattern assumes the operation takes a message input and return a message; it may be that the legacy
        function returns no message or is a notification only and the signature of the operation generated should be
        amended.
    </li>
    <li>
        The architect/designer should ensure that the correct values are specified for the "allowedBindings" property on
        the service provider.
    </li>
</ul></td>
</tr>
</table>
</div>
<div class="stepHeading"> References </div>
<div class="stepContent">
<table class="stepTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td><a id="References" name="References"></a> 
<p>
    [<a id="Ref_CBDI" name="Ref_CBDI">CBDI</a>] Richard Veryard, <i>Modeling for SOA</i>, CBDi Journal February 2003.
</p>
<p>
    [<a id="Ref_SOMA" name="Ref_SOMA">SOMA</a>] Ali Arsanjani, <i>Service-Oriented Modeling and Architecture</i>, IBM
    developerWorks.
</p></td>
</tr>
</table>
</div>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Properties</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<th class="sectionTableHeading" scope="row" id="property_Multiple Occurrences" abbr="Multiple Occurrences">Multiple Occurrences</th><td class="sectionTableCell" align="left" headers="property_Multiple Occurrences"><img width="20" height="15" alt="" title="" src="./../../images/indent.gif"></td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row" id="property_Event Driven" abbr="Event Driven">Event Driven</th><td class="sectionTableCell" align="left" headers="property_Event Driven"><img width="20" height="15" alt="" title="" src="./../../images/indent.gif"></td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row" id="property_Ongoing" abbr="Ongoing">Ongoing</th><td class="sectionTableCell" align="left" headers="property_Ongoing"><img width="20" height="15" alt="" title="" src="./../../images/indent.gif"></td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row" id="property_Optional" abbr="Optional">Optional</th><td class="sectionTableCell" align="left" headers="property_Optional"><img width="20" height="15" alt="" title="" src="./../../images/indent.gif"></td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row" id="property_Planned" abbr="Planned">Planned</th><td class="sectionTableCell" align="left" headers="property_Planned"><img width="20" height="15" alt="" title="" src="./../../images/indent.gif"></td>
</tr>
<tr valign="top">
<th class="sectionTableHeading" scope="row" id="property_Repeatable" abbr="Repeatable">Repeatable</th><td class="sectionTableCell" align="left" headers="property_Repeatable"><img width="20" height="15" alt="" title="" src="./../../images/indent.gif"></td>
</tr>
</table>
</div>
<table class="copyright" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="copyright">Copyright &copy; 2008 版权所有 东软集团股份有限公司&nbsp; 联系邮箱:<a href="mailto:tcoe@neusoft.com">tcoe@neusoft.com</a></td>
</tr>
</table>
</td>
</tr>
</table>
</body>
<script language="JavaScript" type="text/javascript">
					contentPage.onload();
					contentPage.processPage.fixDescriptorLinks();
				</script>
</html>
